Skip to content

Rename provider virtualworkspace to apiexport and add some docs #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Rename provider virtualworkspace to apiexport and add some docs #18

wants to merge 1 commit into from
+79 −28

Conversation

embik
Copy link
Member

@embik embik commented Apr 17, 2025

Summary

I realized that virtualworkspace is a problematic name, given that there are other VWs with different semantics than the APIExport one (e.g. the initializingworkspaces one). Thus, I'm proposing to rename the provider for clarity.

In addition, I've added some light documentation so that the pkg.go.dev page for the provider looks a bit nicer and gives some hints.

What Type of PR Is This?

/kind documentation
/kind api-change

Related Issue(s)

Fixes #

Release Notes

Rename existing `virtualworkspace` provider to `apiexport`

@embik embik requested review from sttts and mjudeikis April 17, 2025 14:03
@kcp-ci-bot kcp-ci-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/documentation Categorizes issue or PR as related to documentation. dco-signoff: yes Indicates the PR's author has signed the DCO. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API labels Apr 17, 2025
@kcp-ci-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from embik. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot kcp-ci-bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Apr 17, 2025
@embik embik force-pushed the rename-provider branch from c2c4ce4 to 6864193 Compare April 17, 2025 14:08
@kcp-ci-bot kcp-ci-bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Apr 17, 2025
@embik embik force-pushed the rename-provider branch from 6864193 to 4c31010 Compare April 22, 2025 07:34
@kcp-ci-bot kcp-ci-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 24, 2025
@embik
Rename provider virtualworkspace to apiexport and add some docs
3b908f8 
On-behalf-of: SAP <marvin.beckers@sap.com>
Signed-off-by: Marvin Beckers <marvin@kubermatic.com>
@embik embik force-pushed the rename-provider branch from 4c31010 to 3b908f8 Compare April 24, 2025 09:45
@kcp-ci-bot kcp-ci-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 24, 2025
@sttts
Copy link
Member

sttts commented Apr 24, 2025

How do other VW differ. We should not a different provider for each. Or at least a largely shared code base.

@embik
Copy link
Member Author

embik commented Apr 25, 2025 •
edited
Loading

How do other VW differ. We should not a different provider for each. Or at least a largely shared code base.

In the initializingworkspaces virtual workspace, the wildcard endpoint only lists LogicalCluster objects, and you have full/unrestricted access to specific logical clusters while they are still initializing. But that means each cluster will potentially be different (i.e. have its own REST mapper), with different already registered APIs, etc.

I agree that code should largely be shared, but I suspect that the slightly different semantics of VWs will force writing your own provider unless you 1:1 implement e.g. the APIExport VW semantics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sttts sttts Awaiting requested review from sttts

@mjudeikis mjudeikis Awaiting requested review from mjudeikis

Assignees
No one assigned
Labels
dco-signoff: yes Indicates the PR's author has signed the DCO. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/documentation Categorizes issue or PR as related to documentation. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@embik @kcp-ci-bot @sttts